@Jayanth-reflex is attempting to deploy a commit to the Elie Team on Vercel.

A member of the Team first needs to authorize it.

Greptile Summary

This PR fixes the root cause of the always-zero newEntryCount badge in the sanctions panel by plumbing timeRange from the UI context all the way through to the API, and adds server-side logic to recompute isNew / per-country / per-program counts based on effectiveAt within the selected window. The wiring changes in App.ts, panel-layout.ts, data-loader.ts, the proto, and the generated stubs are all clean and correct. Two issues in the client-side service layer need attention before the feature works reliably end-to-end:

• Circuit breaker cache is not keyed on timeRange (src/services/sanctions-pressure.ts). The breaker.execute() call omits a cacheKey, so all time-range variants share the same 30-minute cache slot. After the first fetch (e.g. 7d) is cached, switching to 1h silently returns the stale 7d data. AGENTS.md requires request-varying params to be part of the cache key.
• Hydrated bootstrap data bypasses timeRange (src/services/sanctions-pressure.ts). getHydratedData is consume-once, but on the very first call the timeRange argument is ignored and the seed-script's static isNew flags are returned as-is. Users with a non-default time range persisted from a previous session will see incorrect counts on initial load.
• Country/program entries can be silently dropped (server/.../list-sanctions-pressure.ts). countryMap is built by iterating entry countryCodes; any country in data.countries that has no matching entry in the current dataset is omitted from the filtered response when countryMap.size > 0. A safer approach is to start from data.countries and patch in the recomputed counts.

Confidence Score: 4/5

The server-side filtering logic is sound, but two client-side caching bugs will cause incorrect data to be displayed when switching time ranges — the feature's primary user path.

There are two P1 defects in sanctions-pressure.ts: (1) the circuit breaker cache is not keyed on timeRange, so switching windows silently serves stale data from the previous window; (2) bootstrap hydrated data bypasses the timeRange filter on first render. Both directly break the core behaviour this PR is meant to fix. Score 4 to indicate these should be resolved before merging.

src/services/sanctions-pressure.ts — circuit breaker cacheKey and hydration bypass both need fixes here.

Important Files Changed

_{Reviews (1): Last reviewed commit: "fix(sanctions): pass timeRange filter to..." | Re-trigger Greptile}

Good catch — fixed in b92b46d.

The approach now starts from data.countries / data.programs as the base and only patches newEntryCount with recomputed values, so every country and program from the original dataset is always preserved regardless of what entry.countryCodes references.

Before (buggy):

// Built map from entries → looked up in data.countries → silently dropped unmatched
const countryMap = new Map();
for (const entry of retagged) { ... }

After (fixed):

// Start from original data, patch in new counts
const countryNewCounts = new Map();
for (const entry of retagged) { if (entry.isNew) ... }
const countries = (data.countries ?? []).map(c => ({
  ...c, newEntryCount: countryNewCounts.get(c.countryCode) ?? 0,
}));

Same pattern applied to programs.

Both P1 issues fixed in 41a24a8:

1. Circuit breaker cache keyed on timeRange

Each distinct window now gets its own cache slot:

const cacheKey = timeRange || 'all';
return breaker.execute(fn, emptyResult, {
  cacheKey,
  shouldCache: (result) => result.totalCount > 0,
});

clearCache() also receives the same key so only the relevant slot is evicted on empty responses.

2. Bootstrap hydration bypasses timeRange

The hydration path is now skipped when a timeRange is set. The seed-script's static isNew flags can't be re-filtered client-side, so we fall through to the circuit-breaker path which sends timeRange to the server and gets correctly computed counts back:

if (!timeRange) {
  const hydrated = getHydratedData('sanctionsPressure') ...
  if (hydrated?.entries?.length || ...) {
    // only reached when no filter — static flags are valid
    return toResult(hydrated);
  }
}
// timeRange set → always fetch live with the filter applied

@koala73 , kindly review this PR

@SebastienMelki , could you please guide me on how I can get the pending checks done

@SebastienMelki , could you please guide me on how I can get the pending checks done

I just launched the workflows, they should run in a few seconds

@SebastienMelki , could you please guide me on how I can get the pending checks done

I just launched the workflows, they should run in a few seconds

Thanks, @SebastienMelki. I see the Vercel check is failing. Could you please suggest how we can fix this?

Hi @SebastienMelki, @koala73, could you please help me with the Vercel check and retrigger the workflows, so I can merge this PR?

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
worldmonitor	Ready	Preview, Comment	Apr 2, 2026 9:31pm

@koala73 Thanks for the thorough review. All four issues addressed in 0d24bd6:

🔴 P1 — Date.now() frozen in CDN cache

Went with the minimal fix: the generated route handler now sets X-No-Cache: 1 on the Response when time_range is present. The gateway converts this to Cache-Control: no-store, bypassing the static tier's s-maxage=600. Unfiltered requests (no time_range) continue to benefit from full CDN caching.

if (body.timeRange) responseHeaders["X-No-Cache"] = "1";

🔴 P1 — timeRange required → optional

Changed timeRange: string to timeRange?: string in both generated client and server interfaces. Also simplified the dead-code branch:

// Before (else branch never executes — effectiveAt is always string from proto):
const ts = typeof e.effectiveAt === 'string' ? Number(e.effectiveAt) : (e.effectiveAt as unknown as number);
// After:
const ts = Number(e.effectiveAt);

🟡 P2 — onTimeRangeChanged fires unconditionally

Now guarded so it only fires when the sanctions panel is actually mounted:

onTimeRangeChanged: () => {
  if (this.state.panels['sanctions-pressure']) {
    void this.dataLoader.loadSanctionsPressure();
  }
},

🟡 P2 — Shared circuit breaker failure state

Introduced a dedicated filteredBreaker for time-range requests with independent failure counters. The canonical breaker (for 'all') and filteredBreaker (for '1h', '7d', etc.) now have completely separate CircuitState, so failures on one path cannot put the other into cooldown.

const breaker = createCircuitBreaker<SanctionsPressureResult>({
  name: 'Sanctions Pressure',
  cacheTtlMs: 30 * 60 * 1000,
  persistCache: true,
});
const filteredBreaker = createCircuitBreaker<SanctionsPressureResult>({
  name: 'Sanctions Pressure (filtered)',
  cacheTtlMs: 10 * 60 * 1000,
  persistCache: false, // filtered data is time-sensitive, no point persisting
});

Both typecheck and typecheck:api pass cleanly.